AFLI-specs v1.0
by written by D'Arc/Topaz for Chief/Padua on 28.6.1994

Advanged FLI is name I came up with during the time I coded the
first version of AFLI editor. I have never claimed to be the one
who discovered this new graphics mode for 64. I myself give the
credit for COLORFUL/ORIGO but I am not sure if anyone did it
before him (splits have been done but in my eyes they don't count).

In AFLI we can get 120 colors in theory (counted like this
16!/(2!*14!)=120). When we put red and blue hires pixels close to
each other we get a vision of purple - thanks the television.

AFLI is just like FLI with $08-$0f (hires value) in $d016 and a
couple of sprites over the first three marks. With $d018 we
change the start of screen memory. And the good old $d011 for the
main work.

AFLI is the same as FLI but we don't use the $d800-$dc00 area
for the third color. Actually we can't. In normal hires pictures
the colors on the picture is ordered in a normal screen (normal
text screen is on $0400+). The upper 4 bits is the color for
bit 0 in picture bitmap and the lower 4 bits is the color for bit
1 in picture bitmap (or the other way...but let us think that was
the right way).

For example: a normal hires picture char (8x8 bits)

 01234567  in hires picture where  01234567
0 *****    the first spot of the  0bgggggbb
1*** ***   screen has a value of  1gggbgggb
2*** ***   $68 (blue&green) the   2gggbgggb
3*******   hires picture looks    3gggggggb
4*** ***   like this ---->        4gggbgggb
5*** ***   b=blue, g=green        5gggbgggb
6*** ***                          6gggbgggb
7                                 7bbbbbbbb

The bitmap is built just as in a hires picture bit 1 means the pixel
is on and 0 that the pixel is off.

In FLI we have built the screen to have badlines on every scanline of
the screen. This gives us the possibility to change the screenmemory
the picture uses on everyline. Now... when AFLI (and FLI) uses screen
memory for colors and we change the screenmemory start on everyline,
we can have new colors on everyline.

The screens are usually ordered like this.

screen memory used
   0   $4000-$43ff
   1   $4400-$47ff
   2   $4800-$4bff
   3   $4c00-$4fff
   4   $5000-$53ff
   5   $5400-$57ff
   6   $5800-$5bff
   7   $5c00-$5fff
       $6000-$7fff BITMAP (the actual picture data)

The number of the screen is considered as the number of the line in
8x8 pixel area.

An example... Here we have cut from the memory showing the first
bytes in every screen.

screen/rownumber
           00 01 02 03 04 05 06 07 08 09 10 11 12 13 ... 39
     $4000 ff ff ff 56 .. .. ..
     $4400 ff ff ff 67 .. ..
     $4800 ff ff ff 91 ..
     $4c00 ff ff ff b3
     $5000 ff ff ff 54
     $5400 ff ff ff 8f
     $5800 ff ff ff 54
     $5c00 ff ff ff 10

Actually the $ff won't have to be there. It will come to the screen
anyway. We have the same 'A' on the screen on the fourth mark ($6018-
$601f).

  BITMAP               AFLI PICTURE (number is the color number)
 01234567 screenvalue    01234567
0 *****       $56      0 56666655   1=white, 0=black, 2=red ...
1*** ***      $67      1 77767776
2*** ***      $91      2 11191119
3*******      $b3      3 33333333
4*** ***      $54      4 44454445
5*** ***      $8f      5 fff8fff8
6*** ***      $54      6 44454445
7             $10      7 11111111

Now the 'A' surely has a lot of colors.


When we code a FLI routine we know that we have succeeded when we get
a 3 marks wide area filled with value $ff on the screen. In FLI the
thing is easily taken away; we just fill the three first bytes of a
line with empty bytes ($00). In AFLI the value $ff is a color. If we
try to clear the three first marks, we still have the gray area. WHY?
The $ff value comes to the screen.. so... the $ff is a color and
the upper four bits of the byte is the color for empty pixels. We can
not clear the first three marks to wipe the thing off. We have a new
lovely problem: we have to put black (or whatever) sprites over that
area. This is just timing.


This may look very complicated and I think you will still be asking
many questions from me - the text I have written surely ain't the
best novel ever written. I'm great in jumping from a thing to
another.


--
Chief/Padua						  +44 (0) 757 706791
                              --------------------
                        My opinions are not my employers